src/components/video-editor/projectPersistence.test.ts (1)

6-46: ⚡ Quick win

Add coverage for webcam width/height normalization branches.

This suite only asserts padding behavior, but normalizeProjectEditor in this PR also changed webcam.width/webcam.height fallback/clamp logic. Add focused assertions for explicit width/height, legacy size fallback, and clamping.

Proposed test additions

 describe("normalizeProjectEditor", () => {
+	it("normalizes webcam width/height from explicit values and legacy size fallback", () => {
+		const explicit = normalizeProjectEditor({
+			webcam: { width: 88, height: 36, size: 50 } as never,
+		});
+		expect(explicit.webcam.width).toBe(88);
+		expect(explicit.webcam.height).toBe(36);
+
+		const legacy = normalizeProjectEditor({
+			webcam: { size: 55 } as never,
+		});
+		expect(legacy.webcam.width).toBe(55);
+		expect(legacy.webcam.height).toBe(55);
+	});
+
+	it("clamps webcam width/height to allowed range", () => {
+		const editor = normalizeProjectEditor({
+			webcam: { width: 2, height: 1000 } as never,
+		});
+		expect(editor.webcam.width).toBe(10);
+		expect(editor.webcam.height).toBe(100);
+	});
+
 	it("preserves the extended advanced vertical padding range", () => {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/components/video-editor/projectPersistence.test.ts` around lines 6 - 46,
The test suite for normalizeProjectEditor currently only covers padding
normalization behavior and is missing test coverage for the webcam width/height
normalization logic that was also changed. Add new test cases to the describe
block that verify the webcam width/height handling in normalizeProjectEditor,
including tests for: explicit width/height values being preserved, legacy size
property fallback when width/height are not provided, and proper clamping of
webcam dimensions to their maximum values. These tests should follow the same
pattern as the existing padding tests using expect and toMatchObject assertions.

electron/ipc/register/project.ts (1)

301-305: 💤 Low value

Consider resolving symlinks for defense-in-depth.

The isPathInsideDirectory check uses path normalization but doesn't resolve symlinks. A symlink inside projectsDir pointing outside would pass this check, and fs.writeFile would follow the symlink to write outside the trusted directory.

In a desktop app where users have full filesystem control, this is low-risk (users would be "attacking themselves"). However, for defense-in-depth, consider using fs.realpath before the directory containment check:

🛡️ Optional hardening

+      const resolvedExistingPath = existingProjectPath
+        ? await fs.realpath(existingProjectPath).catch(() => path.resolve(existingProjectPath))
+        : null;
       const trustedExistingProjectPath = existingProjectPath &&
         path.extname(existingProjectPath).toLowerCase() === `.${PROJECT_FILE_EXTENSION}` &&
-        (isTrustedProjectPath(existingProjectPath) || isPathInsideDirectory(existingProjectPath, projectsDir))
-        ? path.resolve(existingProjectPath)
+        (isTrustedProjectPath(existingProjectPath) || isPathInsideDirectory(resolvedExistingPath!, projectsDir))
+        ? resolvedExistingPath
         : null

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@electron/ipc/register/project.ts` around lines 301 - 305, The
trustedExistingProjectPath assignment does not resolve symlinks before
validating containment with isPathInsideDirectory, which could allow a symlink
inside projectsDir to escape the trusted boundary. To fix this, resolve the
existingProjectPath using fs.realpathSync before passing it to the
isPathInsideDirectory check, ensuring the actual target location of any symlinks
is validated as being within projectsDir rather than the symlink itself.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes